퍼센트 인코딩

3. URI에서의 퍼센트 인코딩

퍼센트 인코딩 규약은 RFC 3986에 정의되어 있다. 이 규약에 따라 URI에서 사용되는 문자는 의미에 따라 예약(reserved) 문자와 비예약(unreserved) 문자로 나뉜다.
예약 문자는 URI 내에서 특별한 의미를 가질 수 있는 문자들이다. 예를 들어, 슬래시(/) 문자는 URL(또는 더 일반적으로는 URI)의 경로(path) 부분을 구분하는 데 사용된다. 만약 예약 문자를 원래의 특별한 의미가 아닌 일반 문자로 사용해야 할 경우에는 반드시 퍼센트 인코딩을 해야 한다.

반면, 비예약 문자는 특별한 의미를 가지지 않는 문자들이다. 이 문자들은 퍼센트 인코딩을 할 필요가 없으며, 인코딩하지 않는 것이 권장된다.

결론적으로 URI에서 허용되는 문자는 예약 문자, 비예약 문자, 그리고 퍼센트 인코딩 자체를 나타내는 퍼센트 문자(%) 뿐이다. 이 외의 모든 문자는 URI 내에서 사용되기 전에 반드시 퍼센트 인코딩 과정을 거쳐야 한다. 예약된 문자와 비예약된 문자의 정확한 집합 및 특정 예약 문자가 특별한 의미를 갖는 상황은 URI 및 URI 스키마를 규정하는 각 사양 개정판마다 약간씩 변경될 수 있다.

3. 1. 현재 표준

URI에서 위의 예약된 문자 및 비예약된 문자를 제외한 다른 모든 문자는 퍼센트 인코딩되어야 한다.

일반적인 URI 구문은 새로운 URI 스키마를 만들 때, 비예약된 문자는 그대로 표현하고 다른 모든 문자는 UTF-8 인코딩 방식에 따라 바이트로 변환한 다음, 해당 바이트 값을 퍼센트 인코딩할 것을 권장한다. 이 권장 사항은 2005년 1월 RFC 3986의 발표와 함께 도입되었다. 따라서 이 날짜 이전에 만들어진 URI 스키마는 이 권장 사항의 영향을 받지 않는다.

다만 현재 표준 사양에서도 인코딩된 문자 데이터를 어떻게 처리해야 하는지에 대해서는 명확히 다루지 않고 있다. 예를 들어, 컴퓨터 시스템 내에서 문자 데이터는 특정 인코딩 형태로 존재하는데, 이를 URI 문자로 변환할 때 이진 데이터로 처리해야 할지, 아니면 문자 데이터로 처리해야 할지에 대한 명확한 지침이 부족하다. URI 스키마 사양에서 이를 고려하여 처리 방식을 지정하는 것이 바람직하지만, 실제로는 그런 경우가 드물다.

3. 2. 비표준 구현

4. application/x-www-form-urlencoded

HTML 폼에 입력된 데이터를 서버로 전송할 때, 필드 이름과 값은 특정 방식으로 인코딩된다. 이 인코딩된 데이터는 하이퍼텍스트 전송 프로토콜(HTTP)의 GET 또는 POST 메서드를 사용하거나, 과거에는 이메일을 통해 서버에 전달된다.^[4]

이때 사용되는 기본 인코딩 방식은 초기 버전의 일반 URI 퍼센트 인코딩 규칙^[5]을 기반으로 하지만, 몇 가지 수정 사항이 적용되었다. 예를 들어, 개행 문자는 정규화되고, 공백 문자는 %20 대신 + 기호로 변환된다. 이렇게 인코딩된 데이터의 미디어 유형은 application/x-www-form-urlencoded로 지정되며, 이 방식은 현재 HTML 및 XForms 사양에 정의되어 있다. 또한 CGI 사양에는 웹 서버가 이 형식의 데이터를 어떻게 디코딩하여 애플리케이션에서 사용할 수 있는지에 대한 규칙이 포함되어 있다.

웹 폼의 문자열을 HTTP POST 메서드로 전송할 때 이 인코딩 방식이 사용되며, 이때 MIME의 Content-Type 헤더 값으로 application/x-www-form-urlencoded가 명시된다. 이 인코딩 방식을 흔히 '''URL 인코딩'''이라고 부르기도 한다. 표준 문서로는 [https://datatracker.ietf.org/doc/html/rfc1866#section-8.2.1 RFC 1866 HTML 2.0의 Section-8.2.1]에서 처음 등장했다.

데이터 전송 방식에 따라 포함되는 위치가 다르다. HTTP GET 요청으로 전송될 경우, 인코딩된 데이터는 요청 URI의 쿼리 문자열 부분에 포함된다. 반면, HTTP POST 요청이나 이메일을 통해 전송될 때는 데이터가 메시지의 본문에 포함되며, 이때 Content-Type 헤더에 application/x-www-form-urlencoded가 명시된다.

만약 여러 개의 폼 항목(필드 이름과 값 쌍)을 전송해야 하는 경우, 각 항목은 "&"(앰퍼샌드) 문자로 구분되어 하나의 문자열로 합쳐진 후 전송된다.

5. URL 경로, 사용자 정보, 비밀번호에서의 인코딩 (일본어 문서 참고)

URL 표준에서는 URL의 경로 부분을 구문 분석할 때 특정 문자 집합(path percent-encode set)에 해당하는 문자를 만나면, 이를 UTF-8로 부호화한 뒤 퍼센트 인코딩하도록 규정하고 있다. 퍼센트 인코딩이란 바이트 열의 각 바이트를 "%XX" 형태의 문자열로 변환하는 것을 말하며, 여기서 XX는 해당 바이트 값을 나타내는 16진법 숫자이다.

URL의 사용자 정보나 비밀번호 부분에서는 경로 부분에서 요구하는 것보다 더 많은 문자가 퍼센트 인코딩 대상이 된다.^[6]

퍼센트 인코딩에 대한 정의는 URL 표준이 등장하기 이전부터 존재했으며, 대표적으로 RFC 3986 등에서 관련 내용을 찾아볼 수 있다.

5. 1. 인코딩 대상 문자

• C0 제어 퍼센트 인코딩 집합 (C0 control percent-encode set)
• C0 제어 문자 (U+0000 널 문자~U+001F)
• 코드 포인트 값 U+007E보다 상위의 모든 문자
• U+0020 공백
• U+0022 큰따옴표 "
• U+0023 번호 기호 #
• U+003C 작음 <
• U+003E 큼 >
• U+0060 백틱 `
• U+007B 여는 중괄호 {
• U+007D 닫는 중괄호 }

5. 2. 예시

• Shift_JIS - %83E%83B%83L%83y%83f%83B%83A
• EUC-JP - %A5%A6%A5%A3%A5%AD%A5%DA%A5%C7%A5%A3%A5%A2
• UTF-8 - %E3%82%A6%E3%82%A3%E3%82%AD%E3%83%9A%E3%83%87%E3%82%A3%E3%82%A2

참조

_[1] 문서 RFC 1738 §2.2; RFC 2396 §2.4; RFC 3986 §1.2.1, 2.1, 2.5
_[2] 웹사이트 rejected http://www.w3.org/In[...]
_[3] 웹사이트 ECMAScript 2017 Language Specification (ECMA-262, 8th edition, June 2017) https://www.ecma-int[...] Ecma International 2018-06-20
_[4] 문서 User-agent support for email based HTML form submission, using a 'mailto' URL as the form action, was proposed in RFC 1867 section 5.6, during the HTML 3.2 era. Various web browsers implemented it by invoking a separate email program or using their own rudimentary SMTP capabilities. Although sometimes unreliable, it was briefly popular as a simple way to transmit form data without involving a web server or CGI scripts.
_[5] 간행물 RFC 1630 https://tools.ietf.o[...] IETF 1994-06
_[6] 문서 Harvnb url-standard